home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970104-19970326
/
000353_news@columbia.edu _Tue Mar 4 19:32:34 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
2KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA10718
for <kermit.misc@watsun.cc.columbia.edu>; Tue, 4 Mar 1997 19:32:34 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA15497
for kermit.misc@watsun; Tue, 4 Mar 1997 19:32:33 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: FAST+FAST->Window slots 1 of 20
Date: 5 Mar 1997 00:32:31 GMT
Organization: Columbia University
Lines: 31
Message-ID: <5fieuv$md0$1@apakabar.cc.columbia.edu>
References: <5fb64g$5fp@nntp.Stanford.EDU> <5fetck$bde$1@apakabar.cc.columbia.edu> <5fi9d9$ng4@nntp.Stanford.EDU>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:6690
In article <5fi9d9$ng4@nntp.Stanford.EDU>,
Stewart Levin <stew@taal.Stanford.EDU> wrote:
: Thanks for all the suggestions I'm working on trying them out.
: Parity Space did not change the slot count, nor did it affect
: the integrity of the transmission. Sending a big file the
: other direction, PC->Sun did activate 19 of 20 window slots
: over the same connection (and a corresponding satisfying
: increase in throughput.)
:
Well, first of all remember that the number of window slots
in use will never be more than 1 from the receiver's point
of view unless there have been transmission errors, as explained
on page 258 of "Using C-Kermit" 2nd edition. The file sender,
on the other hand, can send a windowful of packets without
receiving any acknowledgements at all, so its window size is
the one that reflects the actual situation.
When the local Kermit program is the receiver, you can check the
number of window slots used by the sender after the transfer by
CONNECTing and giving the remote Kermit a STATISTICS command.
When file transfers go fast in one direction but slow in the
other, that tends to point the finger to the slow receiver.
Check its Kermit settings carefully (window size, packet
length). You said you used FAST on both ends, so it's more
likely something else -- a slow disk, a slow or overloaded
computer or terminal server, etc. If you can be more specific
about the exact type of connection you have and which OS the
PC is using, etc, we can provide better help.
- Frank